Repository navigation
Conversation
Collaborator
Author
|
Performance validation uses frozen wasmvm source Build all runners with Go 1.27.3, LLVM/lld 22.1.8, This is a separate extended-sampling cohort (101 timed calls per process), not the original issue's seven-sample protocol. Twelve blocks each contain two fresh processes for old
The A/A intervals fit the issue's ±2.5% calibration budget. Paired head/main ratio is 0.9580 [0.9536, 0.9667]; head/old is 0.9921 [0.9877, 0.9981]. These are medians of block ratios using the geometric mean of each block's two processes; percentile bootstrap uses 10,000 block resamples and seed The separate fixed-count small/medium allocation benchmark is essentially flat (head/base intervals include 1); this is a validated improvement for the interpreter workload above, not evidence of a universal allocator speedup. Earlier short-sample exploratory cohorts had excessive A/A noise and are not pooled into these results. Raw per-process means for the complete calibrated cohort (ns/iteration): block,old_A,old_B,main_A,main_B,head_A,head_B
1,91.673224,90.549713,92.125447,94.277180,92.074546,91.511842
2,91.210681,90.843809,94.067651,97.256598,92.235936,90.274681
3,91.574752,91.253920,92.567078,94.497857,90.554126,90.364973
4,91.011143,90.467367,94.875950,93.934407,91.739848,88.279285
5,91.623646,91.871162,95.189272,96.333498,89.991100,92.113614
6,93.967244,91.296616,94.718188,94.595495,91.802105,90.990551
7,93.626566,91.114605,95.466210,94.622522,90.196192,91.528664
8,91.917440,90.058494,93.843966,93.583135,89.735446,90.181811
9,91.570132,91.730981,95.319880,95.501735,91.267821,90.842746
10,92.667373,89.727648,97.786926,94.556063,89.632751,92.407222
11,91.125095,92.677230,93.188070,94.223392,91.122116,89.954248
12,91.539191,90.763607,92.757966,92.699014,90.962130,90.983791 |
![fennoai[bot]](https://avatars.githubusercontent.com/in/1924301?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Review summary
The new MakeSlice fast path does the same thing as before. makeSliceMemory runs the same overflow, maxAlloc, len < 0 and len > cap checks, with the same panic messages. With an alignment of 1, the old allocAligned path also ended at AllocZ / AllocAtomicZ. So skipping its alignment check and duplicate maxAlloc check is safe. Memory is still zeroed, slices whose elements contain pointers still get scanned memory, and over-aligned slices still use MakeSliceAligned. The tests cover the zero-length, zero-size, overflow and collector-kind cases well.
Two optional follow-ups, both outside the diff:
runtime/internal/runtime/wide_32bit.go:51-53: On 32-bit targets (386, arm, mips, wasm),MakeSlice64is used for ordinary slices whose length or capacity is wider thanint. It still callsMakeSlice64Aligned(..., 1, ...), which goesMakeSliceAligned→allocZTyped→allocAligned. That is the path this PR removes fromMakeSlice. To match, it could check theint64→intconversion and then callMakeSlice. No test coversMakeSlice64.runtime/internal/runtime/z_slice.go:239: Whencapis larger than the stack buffer or no buffer is available,MakeSliceBufferfalls back toMakeSliceAligned(len, cap, etSize, etAlign, hasPointers). UsuallyetAlignis at most the word size here, because the compiler sends every non-escapingmakethrough the buffer form. So dynamic-capacitymakes that don't escape still take the slower path. CallingMakeSlicewhenetAlign <= unsafe.Sizeof(uintptr(0))would give them the fast path too. The same applies toMakeSlice64Buffer. Whether this matters depends on your workload.
No blocking issues.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
LLGo baseline benchmarks
String equality benchmarks
Program measurements
Core language and compiler benchmarks
Timer runtime benchmarks
Compared with |
LLGo WebAssembly build benchmarks
WebAssembly output sizes
LLGo WebAssembly build measurements
Compared with |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Keep the
MakeSliceentry point on a direct naturally aligned path, sharing boundary checks withMakeSliceAligned:macOS arm64, LLVM 22, O3/full LTO; median timings:
GC workload paired time improves 4.2% (95% CI: 3.3–4.6%); microbenchmarks are unchanged within noise. Protocol and raw block means: 12 randomized paired blocks, 101 samples/process, A/A calibrated.
Validation: full native runtime suite, O0 boundary checks, WASI and Emscripten32/64 O3/full-LTO tests; zeroing, collector kinds, pointer survival and over-alignment remain covered.
Fixes #3045.